Separate types for UserApplicationId and ApplicationId. #3582
Conversation
They are used in different contexts:
Maybe we will be able to get rid of |
There was a problem hiding this comment.
It looks like (EDIT: actually in the works here #3592)ApplicationId<()> is used both internally and in the SDK, and that we're not really going to replace these occurrences by Address.
Ofc we could revisit ApplicationId<A=()>. IMHO the most rigorous choice would be ApplicationId and TypedApplicationId<A> (akin to your previous PR except a different name for the type variant). However, I don't see the issue with ApplicationId<A=()> objectively speaking, and why users would be burdened with a longer name in this case.
|
Also this doesn't look to be a requirement for #3576, is it? |
deuszx
force-pushed
the
alt-separate-application-id
branch
3 times, most recently
from
0085897 to
2a5eec7
Compare
deuszx
force-pushed
the
alt-separate-application-id
branch
from
2a5eec7 to
c81d3eb
Compare
|
Postponed for the time being and addressed (partially) in #3626 |
Motivation
We want to fix and expand our notion of
Address(currentlyOwner,GenericApplicationId, etc.) to different type of addresses (32-byte Linera/Solana, 20-byte EVM). In order to do that we need to prepare the code for the introduction of new variants.Proposal
Add a separate type for
UserApplicationId(hash)vsApplicationId(a hash + type-safe ABI). Previously the presence ofAtype parameter in "address" enum made it more difficult to refactor. After this PR we have separate types for application's address and application with ABI (used mostly in tests and CLI now).Note: This is an alternative to #3570 . Where I kept the
UserApplicationIdname but promoted it to a newtype.Test Plan
CI should catch regressions.
Release Plan
Links